1 HARDWARE PAY-PER USE 

2 Technical Field 

3 The technical field is pricing of hardware on a per-use basis. 

4 Background 

5 Many businesses, especially Internet-based enterprises, face increasing demands 



6 for computing capacity. As these demands for computing capacity have grown, a typical 

7 approach has been to continue to acquire enough computing capacity (i.e., hardware 

8 devices) to meet some service level objective, which was usually in excess of a normal 

9 service level. Alternately, or in addition, additional computing capacity may be desirable 

10 in the event of a casualty that results in loss of one or more hardware devices so as to 

1 1 maintain uninterrupted the desired service level. This traditional approach to acquiring 

12 computing capacity translates into costly oversizing or the risk of low service levels. For 

13 example, to provide service at an Internet Web site, the Web site operator might acquire 

14 enough server capacity to handle 80 percent of peak load. This meant that at peak, some 

15 Web site customers might not be able to access the Web site, while at off-peak hours, 

16 some servers might be idle. The closer the Web site operator tried to come to handling 

17 peak load, the larger the idle server capacity would be in off-peak hours. 

18 Summary 

19 A hardware pay-per-use system and corresponding method allow computer 

20 system clients to tailor their hardware utilization to more closely match changing 

21 customer demands. The system and corresponding method allow a client to react quickly 

22 to changes in demand or hardware failure and to maintain desired service levels without 

23 expensive acquisition of excess hardware capacity. The system and method incorporate 

24 flexible pay-per-use pricing plans based on data gathered from hardware products by a 

25 mechanism separate and distinct from the hardware products. 

26 In an embodiment, the hardware pay-per-use system includes one or more 

27 hardware products and a metering mechanism coupled to the hardware products. The 

28 metering mechanism includes a hardware device separate from the hardware products. 

29 The metering mechanism acquires metrics data from the hardware products, the metrics 

30 data related, for example, to usage of the hardware products. The metering mechanism 

31 determines data to report on the usage of the hardware products. A usage repository 

32 coupled to the metering mechanism receives the determined data and generates usage 

33 reports related to the hardware products. In addition, billing reports and invoices may be 

34 generated based on the usage data. 
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A method for pricing hardware on a pay-per-use basis, wherein one or more 
hardware products are coupled to a communications network, includes acquiring, in a 
hardware device separate from one or more hardware products, metrics data related to an 
operation, such as usage, of the hardware products; determining data to report based on 
the acquiring step; sending the determined data to a usage repository; generating a usage 
report; and generating a pay-per-use billing report and an invoice based on the usage 
report. 

Description of the Drawings 

A hardware pay-per-use system, and corresponding method, will be described in 
detail with reference to the following figures, in which like numerals refer to like 
elements, and in which: 

Figure 1 is a block diagram of a hardware pay-per-use environment; 

Figure 2 is a detailed block diagram of a hardware pay-per-use system; 

Figure 3 is a block diagram of a metering mechanism used with the system of 
Figure 2; and 

Figure 4 is a flowchart illustrating an operation of the system of Figure 2. 
Detailed Description 

Figure 1 is a block diagram of a hardware pay-per-use environment 10 that allows 
for flexible pricing of hardware products. The flexible pricing may apply to any number 
of financing models, including leasing, pre-payment, capital purchase, rent-to-own, 
purchase and trade-in, and other financing models. The environment 10 includes a client 
side 11 having one or more hardware products 12. Also included is a mechanism 13 
capable of obtaining data related to operation of the hardware products 12. The hardware 
products 12 are coupled to the mechanism 13 through a connection 14. Coupled to the 
client side 1 1 through a connection 18 is a server side 15. The server side 15 may include 
one or more servers 16 to process data and to support the flexible pricing, and one or 
more databases 17 to store data related to the flexible pricing. 

The hardware products 12 may be servers designed to operate in a networked 
computer system. However, the hardware products 12 may be any hardware devices that 
may be attached to a network, and from which metrics data may be obtained. In the 
environment 10 shown in Figure 1, the hardware products 12 are leased to a client at the 
client side. In an alternative embodiment of the environment 10, the hardware products 
12 may be provided based on other financing models, such as pre-payment, capital 
purchase, rent-to-own, purchase and trade-in, and other financial models, for example. 
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1 The hardware products 12 may be designed to meet a service level specified by the client. 

2 For example, the client side 11 may be an Internet Web site, the hardware products 12 

3 may be Web servers, and the number of Web servers leased may be chosen by the client 

4 so that an expected peak demand at the client side 1 1 may always be satisfied through 

5 operation of the Web servers. Under these assumptions, the hardware products 12 (Web 

6 servers) may not realize 100 percent or near 100 percent utilization for much of any given 

7 time period. As a consequence, and under a traditional hardware product leasing plan, the 

8 client would pay for excess capacity that may be seldom used, in order to guarantee an 

9 acceptable service level during hours of peak operation. The environment 10 solves this 

10 problem by a flexible financing model based on a pay-per-use scheme. The pay-per-use 

11 scheme provides that the client pay for hardware products 12 based, at least in part, on 

12 metrics data acquired from the hardware products 12 by the mechanism 13. The metrics 

13 data may relate to, or measure, some operational aspect of the hardware devices 12, such 

14 as a period of time the hardware devices 12 are actually in use, for example. Other 

15 metrics data, including configuration data, may also be used as a basis for billing in the 

16 pay-per-use scheme. 

17 The hardware products 12 that are leased to the client in the environment 10 may 

18 be provided by an operator of the server side 15, or by an entity related to the operator of 

19 the server side 15. Alternatively, the provider of the hardware products 12 and the 

20 operator of the server side 15 may be unrelated entities. 

21 The mechanism 13 may be provided at the client side 11 by the provider of the 

22 hardware products 12, the operator of the server side 1 5, or another entity unrelated to the 

23 provider or the operator. The mechanism 13 may be an appropriately programmed 

24 hardware device that is physically distinct from the hardware products 12. The 

25 mechanism 13 may be implemented as a hardware device in a rack mountable system in 

26 which the hardware products 12 are also mounted. In this embodiment, the mechanism 

27 13 may be a standalone device. The mechanism 13 may also be implemented on a 

28 suitably programmed general purpose computer, including a laptop or notebook 

29 computer, a desk top computer, a server, and a main frame computer. The mechanism 13 

30 may not be resource-intensive, and may be implemented as a device with less computing 

31 capability than the hardware products 12. The mechanism 13 may incorporate features 

32 (not shown) that allow the client at the client side 1 1 to obtain information related to 

33 operation of the hardware products 12. For example, the client may be able to query the 
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mechanism 13 to obtain a running bill for operation of the hardware products 12, or to 
obtain metrics data collected by the mechanism 13. 

When the mechanism 13 is provided at the client side 1 1, the connection 14 may 
be any connection capable of transmitting digital data, and the connection 18 may be the 
Internet, or a similar public network capable of transmitting digital data. 

In an alternative embodiment of the environment 10, the mechanism 13 may be 
located at the server side 15. In this embodiment, the connection 18 may be any medium 
capable of transmitting digital data, and the connection 14 may be a public network, such 
as the Internet, that is capable of transmitting digital data. 

Figure 2 is detailed block diagram of one possible hardware pay-per-use system. 
A hardware pay-per-use system 100 includes a client side 110 and a server side 115. The 
client side 110 is coupled to the server side 115 by connection 118, client-side firewall 
108 and server side firewall 119. The connection 118 may be any connection capable of 
transmitting digital data. In an embodiment, the connection 118 is a communications 
network, and the client side 110 is an Internet Web site. In an alternative embodiment, 
the connection 1 18 is a communications link in a local area network (LAN), and the client 
side 110 and the server side 1 15 are nodes in the LAN. Those of ordinary skill in the art 
will appreciate that the system 100 shown in Figure 2 can be adapted to any network or 
environment in which digital data are passed from one node to another node. 

The client side 110 is shown with three hardware products 112 coupled to a 
metering mechanism 1 13, which may include a display 107. However, the client side 110 
may include any number of hardware products 1 12. In an embodiment, additional 
metering mechanisms 113 may be emplaced at the client side 110 should the number of 
hardware products 112 exceed a capacity of a single metering mechanism 113. The 
functions of the metering mechanism 113, and its relation to the hardware products 112, 
will be described in detail later. Coupled to one or more of the hardware products 112 
may be a metering agent, such as the agent 109. The hardware products 112 may also 
include bundled software, such as the bundled software 106. 

In an alternate embodiment of the system 100, the metering mechanisms 113 are 
located at the server side 1 15 on the server side of the firewall 119. In this embodiment, 
the metering mechanism 113 communicates with other devices at the server side 115 
using a digital data transmission medium, and communicates with the hardware products 
112 at the client side 110 using Virtual Private Network (VPN) technology, or similar 
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1 technology, implemented on a public network, such as the Internet, or other network 

2 capable of transmitting digital data through the firewalls 1 19 and 108. 

3 The server side 115 includes a usage repository 120 that receives data from the 

4 metering mechanism 113. The usage repository 120 includes means for receiving metrics 

5 data associated with the hardware products 1 12, validating the metrics data, and storing 

6 the data. In an embodiment, the means for receiving, validating, generating and storing is 

7 a utility validation server 121. The usage repository 120 may also include means for 

8 generating usage reports based on metrics data. The server 121 may store processed and 

9 raw (unprocessed) data and the usage reports in one or more usage databases 123. 

10 Coupled to the usage repository 120 are a portal 130 and a billing and accounting 

11 system 140. The portal 130 provides communications means that allow a client at the 

12 client side 110 to interact with the server side 115, and provide a means for bill 

13 presentation and payments in the hardware pay-per-use system 100. The portal 130 also 

14 allows the client at the client side 1 10 to view data associated with the hardware products 

15 1 12. In an embodiment, the portal 130 may provide for display of data from the server 

16 side 115 onto the display 107 at the client side 110. An example of this data includes 

17 hardware product usage reports that may be generated at the usage repository 120. The 

18 billing and accounting system 140 provides means for generating billing information, 

19 receiving and crediting payments from the client side 110, completing other 

20 administrative tasks and storing data related to these functions. 

21 Returning to the client side 110, the hardware products 112 may be servers that 

22 are leased from an operator of the server side 115. The hardware products 1 12 may also 

23 be other leased, computer-related hardware devices, including printers, desktop 

24 computers, and other hardware devices. In addition to a leasing model, other financial 

25 models, such as pre-payment, capital purchase, rent-to-own, purchase and trade-in, and 

26 other financial models may be used to provide the hardware products 112. Although the 

27 system 100 shown in Figure 2 illustrates the hardware pay-per-use concept in the context 

28 of a networked computer system, i.e., the system 100, the hardware pay-per-use concept 

29 may be used for other hardware environments in which metrics data related to operation 

30 of the hardware products can be collected from the hardware products and provided to a 

3 1 remote location for usage and billing purposes. In another embodiment of the system 

32 100, the hardware products 112 may be acquired from a hardware vendor, and the 

33 monitoring and billing functions may be executed by a third-party vendor. In still another 

34 embodiment, the system 100 is a LAN with the client side 110 as one of one or more 
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1 nodes in the LAN, and the server side 115 as a central node on the LAN. In this later 

2 embodiment, the server side 115 tracks hardware product usage by the client side 110, 

3 and may establish internal billing for use of the hardware products 112. 

4 The metering mechanism 113 acquires usage or metrics data from one or more of 

5 the hardware products 1 12. The metering mechanism 113 may be a standalone hardware 

6 device that is suitably programmed to acquire the metrics data. For example, the 

7 metering mechanism may be a rack-mounted component coupled to the hardware 

8 products 1 12. Alternatively, the metering mechanism 113 may reside on a non-pay-per- 

9 use hardware component, such as an administrative server, for example, at the client side 

10 110. In an embodiment, the metering mechanism 113 contains metrics-data acquisition 

1 1 software, such as Hewlett-Packard Open View Internet Usage Manger (IUM) running as 
jf 12 the only application on a separate, no maintenance, Linux-based system residing at the 
5 1 3 client side 110. In yet another embodiment in which the metering mechanism 1 1 3 resides 
X 14 at the server side 1 1 5, the metering mechanism 1 1 3 may be a standalone hardware device, 
N; 15 or may be incorporated into one or more components on the server side 115, such as the 
U 16 usage repository 120, for example. When the metering mechanism 1 13 is implemented at 
L 17 the server side 115, VPN technology, or other similar technology that allows the 
P 18 hardware products 1 12 to communicate with the metering mechanism 113, may be used 
m 1 9 in connecting the hardware products 1 1 2 to the server side 115. 

0 20 The metering mechanism 1 13 may acquire the metrics data on a periodic or non- 
21 periodic basis. One approach to collecting the metrics data relies on a polling operation. 

22 In the polling operation, the Internet protocol (IP) addresses of each of the hardware 

23 products 1 12 is entered into the metering mechanism 113. The entry of the IP addresses 

24 may be completed using a graphical user interface (GUI), for example. The metering 

25 mechanism 113 then polls the hardware products 1 12 at the client side 110 using the IP 

26 addresses in order to retrieve the metrics data. The hardware products 112 receive the 

27 polling command, and initiate action to collect the required metrics data. Such collection 

28 may rely on the metering agent 109, which may be a Windows® or Linux agent, for 

29 example, incorporated into each of the hardware products 112. In addition, each of the 

30 hardware products 112 may have a different polling interval, even for like or similar 

3 1 hardware products 112. 

32 In an alternative to polling, the metering mechanism 1 1 3 may rely on the metering 

33 agents to collect the metrics data without polling. In this embodiment, metering agents, 

34 such as the metering agent 109, collect the metrics data continually or at specified 
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collection intervals and initiate communication with the metering mechanism 113. The 
metering mechanism 113 may be set to receive metrics data from the metering agents 
109. 

The metering mechanism 113 may acquire metrics data several times per hour, 
depending on the type of metrics data that is being collected. For example, the metering 
mechanism 113 may be set to acquire data every 20 minutes for a total of 72 intervals per 
day. Other acquisition intervals, however, may be specified depending on the type of 
metrics data being collected. Frequent acquisition may be desired for instantaneous, or 
snapshot metrics; however, frequent polling would not be as critical for cumulative 
metrics. The metering mechanism 113 may have a single acquisition interval in order to 
simplify matters. 

The metering mechanism 113 may acquire metrics data from the hardware 
products 1 12 using a variety of techniques. The metrics data may be acquired in a variety 
of formats. The metering mechanism 113 may acquire different metrics data from 
different hardware products 112, and the hardware products 112 at any one client side 
need not be identical or even similar types of hardware devices. The metering 
mechanism 113 may perform some pre-processing of the metrics data, and may send the 
pre-processed metrics data to the usage repository 120 after suitable compression and 
encryption. 

The metering mechanism 113 may communicate with the hardware products 112 
through a network management protocol such as Simple Network Management Protocol 
(SNMP) or Web-Based Enterprise Management (WBEM) protocol, both of which allow 
polling of information. The metering mechanism 1 13 and the hardware products 1 12 also 
can communicate using a Desktop Management Interface (DMI), or similar framework 
for network management. The metering mechanism 113 and the hardware products 112 
may communicate and transmit data using protocols that are not specifically dedicated to 
network management, such as Hypertext Transport Protocol (HTTP) or Secure HTTP 
(HTTP/S). 

As noted above, the hardware products 112 may incorporate the metering agent 
109 to communicate with the metering mechanism 113. The implementation of the 
metering agent 109 will depend on the particular communication protocol being used. In 
a SNMP implementation, the metering agent 109 is implemented as a SNMP agent or 
sub-agent. If WBEM/DMI is the communication protocol, a WBEM/DMI data provider 
serves as the metering agent 109. A CGI program accessible to a Web server could be 
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1 used as the metering agent 109 if HTTP or HTTP/S is used as the communication 

2 protocol. 

3 Metrics data returned by the hardware products 112 may use a standardized data 

4 structure such as one specified by management information base (MIB) for SNMP or by 

5 the Managed Object Format (MOF) for WBEM. In a SNMP implementation, for 

6 example, a MIB can be specified for returning certain data to the metering mechanism 

7 113. The MIB could be compiled into a data structure and downloaded to the metering 

8 agent 109 (implemented, for example, as a SNMP subagent) where the data structure 

9 would be used in collecting data. Other data structures may be used to implement the 

10 transfer of the metrics data between the hardware products 112 and the metering 

11 mechanism 113. 

12 The particular metrics data gathered from the hardware products 112 depend on 

13 the particular hardware product 1 12 and a particular business model for charging for use 

14 of the hardware products 112. One type of metrics data that may be acquired is a 

15 snapshot metric, which represents a snapshot of the current state of the hardware products 

16 112 at the client side 110. One common type of snapshot metric, for example, is the 

17 number of hardware products 112 operating at the client side 110 at any one time. 

18 Cumulative metrics data, which measure the total accumulated value of a given 

19 parameter, may also be acquired by the metering mechanism 113. Such cumulative 

20 metrics data include the number of transactions or the number of files being produced for 

21 a given pre-determined time interval, for example. Other metrics data include central 

22 processing unit (CPU) utilization or execution time and input/output (I/O) metrics such as 

23 number of I/O reads or writes. Still other metrics data include how much memory out of 

24 available memory is being used at any time, how much hard disk, or other mass storage, 

25 is used at any time; bandwidth-related metrics such as the number of megabytes 

26 transmitted through a network interface card (NIC) over a given time; the number of files 

27 accessed over a given time; and the number of connected users, for example. 

28 The client may also specify (and the server side operator agree to) client-supplied 

29 metrics data on which the pay-per-use bill or invoice is based. For example, the client 

30 side 110 may be an online brokerage company. In this example, the pay-per-use bill may 

31 be based on a number of trade transactions processed through the brokerage company's 

32 Web server(s) (the hardware products 112) over a given time. The number of 

33 transactions may be determined by a metering agent provided by the server side operator 

34 or other third-party entity, where the metering agent is installed on the hardware products 
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1 112 at the client side 110, as described above. Thus, the system 100 is able to 

2 accommodate customized schemes for reporting and using metrics data so as to most 

3 accurately account for hardware product usage by a specific client. 

4 The metering mechanism 113 may return the metrics data in a specific pre- 

5 determined data interface, such as a colon-separated variable text format or rows of 

6 variable/value groups, that is compatible with the metering mechanism 113. The metrics 

7 data may be in binary format or in text format, for example. 

8 The metering mechanism 1 13 may periodically report or transmit the accumulated 

9 metrics data to the server side 115. The reporting periodicity may be determined on a 

10 calendar basis, on an accumulated number of bytes of data, or some other basis. For 

11 example, the metering mechanism 113 may accumulate one days worth of metrics data 

12 from the hardware products 112. At a specified time, the metering mechanism 1 13 may 

13 establish communications with the server side 115, and then upload the accumulated 

14 metrics data. 

15 When implemented at the client side 110, the metering mechanism 113 may 

16 acquire the metrics data from the hardware products 112, and, at a specified time, may 

17 establish communications with the server side 115 to transmit the metrics data. Such 

18 communications may be established by the metering mechanism 113 using an IP address 

19 of the server side 115 to open a communications path, for example. In this embodiment, 

20 metrics data transmission is initiated by the metering mechanism 113, and the server side 

21 115 may initiate queries, such as e-mail messages with the client side 110. The metrics 

22 data are then "pushed" to the server side 115. 

23 When implemented at the client side 110, the metering mechanism 113 may 

24 transmit the metrics data to the server side 115 using a variety of known protocols, and 

25 network transport mechanisms, including HTTP and HTTPLS, for example. The 

26 transmission may be automatic, using a proxy server (not shown) at the client side 110, 

27 and/or Network Address Translation (NAT) to communicate through the firewalls 108 

28 and 119 over the Internet. The metering mechanism 113 may also transmit the metrics 

29 data using e-mail by way of the Internet. 

30 When implemented at the server side 115, as described above, the metering 

31 mechanism 1 13 may initiate acquisition of the metrics data from the hardware products 

32 112 by, for example, using an IP address of the client side 110 and the hardware products 

33 1 12. The metering mechanism 113 then "pulls" the metrics data from the client side 1 10. 
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When implemented at the server side 115, the metering mechanism 115 may use 
network transport mechanisms and protocols, as described above, to acquire the metrics 
data from the hardware products 112. 

The metering mechanism 113, when implemented at the client side 110, may 
receive any patches, or software updates from the server side 115. The metering 
mechanism 113 may query the server side 115 periodically, such as daily, to receive such 
updates. Alternatively, the metering mechanism 113 may receive the updates upon 
communicating with the server side 115 for the purpose of transmitting the metrics data. 
Thus, the metering mechanism 113 incorporates the capability to be dynamically updated. 
Similarly, the metering mechanism 113 may receive patches for updating operation of 
one or more of the hardware products 112. 

The metering mechanism 113 also provides the client side 110 with the means for 
updating a configuration of the hardware products 112. For example, should an 
additional hardware product 1 12 be added at the client side 1 10, the metering mechanism 
113 can provide updated hardware product information to the server side 115, including 
an identity of the additional hardware product 112, and any metrics data that will be 
gathered from the new hardware product 112. The stored hardware product configuration 
can also be downloaded to the client side 110 should an existing metering mechanism 1 13 
be replaced, or should an additional metering mechanism 113 be added at the client side 
110. 

The metering mechanism 1 1 3 may incorporate many components or features that 
allow operation in a variety of network environments. Figure 3 is a block diagram 
showing an embodiment of the metering mechanism 113 that may be implemented at the 
client side 110. The metering mechanism 113 includes a rules engine 151, a processor 
153, a display driver 155, a communications engine 157, a data acquisition engine 159, 
and a database 161. The rules engine 151 may be programmed with generic and specific 
rules that relate to the capture and reporting of metrics data from the hardware products 
112. For example, the metering mechanism 113 may be designed, for the specific client 
side 1 10, to continually acquire CPU utilization, and to record CPU utilization every five 
minutes. The rules engine 151 may be programmed to require that the CPU utilization 
value reported to the server side 115 be a peak CPU utilization for each five minute 
interval. Alternatively, a rule could specify that an average CPU utilization for each five 
minute interval is to be reported to the server side 115. The rules in the rules engine 151 
may also relate to a pay-per-use pricing plan agreed to by the client and the server side 
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1 operator. For example, the pay-per-use pricing plan may specify a first billing rate, which 

2 may be a flat or minimum fee, if average CPU utilization over a 24-hour period is less 

3 than 20 percent, and a second billing rate, which may vary, if the CPU utilization is equal 

4 to, or greater than, 20 percent. 

5 The processor 153 may provide a variety of computing functions for the metering 

6 mechanism 1 13 and may control operation of the metering mechanism components. The 

7 processor 153 may also provide some pre-processing of the metrics data acquired from 

8 the hardware products 112. For example, the processor 153 may produce an average of 

9 CPU utilization for each five minute interval in a day. The processor 153 operates with 

10 the rules engine 151 to ensure that metrics data as specified by the pay-per-use pricing 

11 plan is acquired, processed and packaged for transmission to the server side 115. For 

12 example, if the pay-per-use pricing plan specifies that the hardware product financing rate 

13 will be based on average CPU utilization, with the average determined over each five 

14 minute interval, the processor 153 will compute the average CPU utilization, and will 

15 make the average CPU utilization available for transmission to the server side 115. The 

16 processor 153 may also incorporate certain data path integrity checks. For example, the 

17 processor 153 may incorporate routines for testing the hardware product to metering 

18 mechanism transport mechanism, such as SNMP, WBEM or HTTP, by obtaining a 

1 9 known response from the metering agent 1 09. 

20 The display driver 155 may include software required to display information to 

21 the client at the client side 110. The information may be displayed on a monitor, a 

22 printer, or other display device that is coupled to the metering mechanism 113. The 

23 information may also be displayed over the network 1 18 to a Web browser installed on a 

24 hardware device at the client side 1 1 0. Examples of information that may be displayed at 

25 the client side include instantaneous and average CPU utilization, total or average CPU 

26 utilization over 24 hours, and other metrics data, including pre-processed metrics data 

27 collected at the metering mechanism 1 1 3 and diagnostic and help information. 

28 The communications engine 157 includes the necessary programming to encrypt, 

29 compress, and package the metrics data, including pre-processed metrics data, for 

30 transmission to the server side 1 1 5 in a format that is compatible with the connection 1 1 8 

3 1 and the server side components. 

32 The data acquisition engine 159 includes the programming needed to acquire data 

33 from the hardware products 112. The programming includes the necessary interfaces to 

34 communicate with any metering agents installed on the hardware products 112. The 
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programming may also dictate the manner in which metrics data is to be acquired. For 
example, the programming may specify that the metering mechanism 113 is to poll each 
of the hardware products 112 at a specific interval (e.g., every five minutes) to retrieve 
the required metrics data. The data acquisition engine 159 may also digitally sign the 
metrics data so that any data tampering may be detected. 

The database 161 stores a variety of data related to the pay-per-use pricing plan. 
The database 161 may store metrics data, including pre-processed metrics data, prior to 
transmission of the metrics data to the server side 115. For example, the database 161 
may store metrics data for 24 hour intervals, with the metering mechanism 113 
transmitting the metrics data to the server side 115 every 24 hours. The database 161 
may continue to store the metrics data until the metering mechanism 113 receives a 
direction from the server side 115 that the metrics data may be deleted from the database 
161 . In this way, the server side 1 1 5 may validate, and ensure the accuracy and adequacy 
of, the metrics data before the metrics data are deleted. The database 161 may store other 
data and information, such as hardware product configuration, bills or invoices, and other 
information related to the operation and administration of the pay-per-use pricing plan. 

As noted above, the metering mechanism 113 periodically transmits the metrics 
data to the server side 115. The periodicity for reporting metrics data may vary from 
client side to client side, and within a specific client side, may vary from hardware 
product to hardware product. In an embodiment of the system 100, the metrics data are 
transmitted to the server side 1 1 5 daily. If, after a specified time, such as three days, the 
server side 115 has not received any metrics data from the client side 110, an e-mail 
notification may be sent to a specified e-mail address at the client side 110. Alternatively, 
or in addition, should metrics data for the client side 110 not be received at the server side 
115, then the client side 110 may be charged a set fee for the period for which no metrics 
data were delivered. For example, the client could be invoiced at 50 percent of maximum 
utilization for every period not covered by the metrics data. The usage repository 120, 
and in particular the validation server 121, then process the collected metrics data as a 
step in completing a bill or invoice for usage of the hardware products 112. The 
validation server 121 may decrypt and decompress the metrics data, and then execute a 
number of routines to validate the data prior to processing for bill generation. 

The validation server 121 may perform one or more validation or audit functions 
based on the metrics data received from the client side 110. A first, or configuration, 
validation function may relate to ensuring an original, approved configuration of the 
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1 hardware products 1 12 at the client side 110 has not been altered or modified by the client 

2 or some other entity. The configuration validation may be based on a configuration file 

3 for the client side 110 that is stored in the usage database 123. As noted above, as the 

4 hardware product configuration at the client side 110 changes (through approved 

5 processes, such as revised financing arrangements, or hardware product upgrades), the 

6 hardware product configuration file for the client side 110 may be updated. The hardware 

7 product configuration, in the case of a Web server, for example, may be changed by 

8 adding or subtracting a processor, adding or subtracting memory, or adding or subtracting 

9 hard drives. 

10 As an alternative means for validating the configuration, the validation server 121 

1 1 could note the hardware product configuration when metrics data are received from the 

12 client side 110, and may store this configuration in the usage database 123. The next time 

13 that the validation server 121 receives metrics data from the same client side 110, the 

14 validation server 121 may receive the current hardware product configuration. The 

15 validation server 121 may then compare the current hardware product configuration to the 

16 previous hardware product configuration stored in the usage database 123. Any 

17 differences in hardware product configuration may be noted, and may cause the 

18 validation server 121 to execute a specific action, including, for example, generation of an 

19 error message for display to operators of the server side 115. An updated hardware 

20 configuration file may be available to the client through the metering mechanism 1 13, or, 

21 as discussed below, through the portal 130. 

22 Other validation functions may relate to the format and acceptability of the 

23 metrics data. For example, the validation server 121 may ensure the metrics data are not 

24 corrupted, that the metrics data received from the client side 110 falls within a range of 

25 expected values for the data, and other validation checks. As a specific example, if the 

26 client side 110 has three Web servers as the hardware products 112, and the received 

27 metrics data relates to hours or percentage of CPU utilization, then the maximum number 

28 of hours for all three Web servers in one day would be 24 hours each, and the maximum 

29 percent CPU utilization would be 100 percent. Any metrics data exceeding these 

30 maximum values would be in error, and the validation server 121 could note the error 

31 event, halt processing, and generate an error message. The validation server 121 could 

32 incorporate other criteria or rules by which to judge the accuracy and adequacy of the 

33 received metrics data. The validation server 121 may also check the received metrics 

34 data to determine if someone has tampered with the metrics data as collected at the 
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1 hardware products. This tamper checking process may be executed by using the digital 

2 signature, mentioned above, that may be appended to the metrics data by the metering 

3 mechanism 113. Other error-checking and testing routines may be incorporated into the 

4 system 100. For example, the integrity of the client side to server side transport 

5 mechanism, where the transport mechanism uses HTTP or HTTPLS protocols, may be 

6 verified by uploading a test file from the metering mechanism 1 1 3 to the usage repository 

7 120. 

8 The usage database 123 stores metrics data, including metrics data pre-processed 

9 by the metering mechanism 113 and processed by the validation server 121, and 

10 unprocessed metrics data for each of the connected client sides 110. The usage database 

11 123 also stored hardware product configuration data, usage reports, and other data related 

1 2 to operation and administration of the pay-per-use pricing plan. 

13 Returning to Figure 2, the portal 130 serves as a communications interface 

14 between the client side 1 10 and the server side 115. The portal 130 provides means by 

1 5 which the client may view data at the server side 1 1 5, and means for bill presentment and 

16 payment. The portal 130 includes a usage reports mechanism 131 by which the client 

17 may be presented with information related to operation of the hardware products 112. In 

18 particular, the usage reports mechanism 131 may provide the client with access to all 

19 processed and unprocessed metrics data for the client side 110. The usage reports 

20 mechanism 131 may also provide means for the client to communicate with the server 

2 1 side 1 1 5, to inquire about the hardware products 1 12, the pay-per-use lease plan and other 

22 administrative and accounting matters. Access to the portal 130 by the client may be 

23 controlled using various security measures such as a user name and password, for 

24 example. A bill presentation mechanism 133 may be used to provide the client side 110 

25 with an electronic copy of a current bill or invoice. The mechanism 133 may provide the 

26 invoice as an e-mail attachment, a down loadable electronic file posted on a server Web 

27 site, or any other form of electronic bill presentment. A bill payment mechanism 135 

28 may allow the client to pay for lease of the hardware products 1 12 using a standard form 

29 of electronic funds transfer; payment by credit card or other form of payment over a 

30 communication network. The bill payment mechanism 135 may also provide a toll-free 

3 1 (800) number by which the client can call to arrange a payment on the invoice. 

32 The billing and accounting system 140 includes a billing system 141, a 

33 administration system 143, and a billing/administration database 145. The billing system 

34 141 receives usage data from the usage repository 120, and generates a bill or invoice for 
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1 presentment to the client using the portal 130. The administration system 143 performs 

2 various administrative function for the server side 115. The database 145 stores various 

3 billing and administrative data, including client data. 

4 As shown in Figure 2, the billing and accounting system 140 is incorporated into 

5 the server side 115. However, the billing and accounting system 140 may be located at a 

6 site remote from the server side 115, and may be operated by an entity other than the 

7 server side operator. 

8 Figure 4 is a flowchart illustrating an operation 200 of the system 1 00 of Figure 2 

9 in which the metering mechanism 1 1 3 is located at the client side 110. The operation 200 



10 relates to metrics data collection and billing, and begins in block 205. In block 210, the 

1 1 metering mechanism 113 polls the hardware products 1 12 at the client side 1 10 in order 
y> 12 to retrieve metrics data. In block 215, the hardware products 112 receive the polling 
S 13 command, and initiate action to acquire/or provide the required metrics data. Such 
S 1 4 acquisition may rely on a metering agent incorporated into each of the hardware products 
M 15 1 1 2. In addition, each of the hardware products 1 1 2 may have a different polling interval, 
U 1 6 even for like or similar hardware products 1 12. The hardware products 1 12 then transmit 
L 1 7 the metrics data to the metering mechanism 113. 

1 8 In an alternative to polling, the metering mechanism 1 1 3 may rely on the metering 

: - 19 agents to provide the metrics data without polling. In this embodiment, the metering 

O 20 agents collect the metrics data at specified collection intervals and initiate communication 

21 with the metering mechanism 113. The metering mechanism 113 may be set to receive 

22 metrics data from the metering agents. The metering mechanism 1 13 may collect metrics 

23 data several times per hour, depending on the type of metrics data that is being collected. 

24 For example, the metering mechanism 1 1 3 may be set to collect data every 20 minutes for 

25 a total of 72 intervals per day. 



26 In yet another alternative, the metering mechanism 113 may access certain 

27 operating data related to the hardware products 1 1 2 in order to gather the metrics data. 

28 In block 220, the metering mechanism 113 stores the collected metrics data. In 

29 block 225, the metering mechanism 113 may perform any required pre-processing of the 

30 acquired metrics data. Any pre-processed metrics data may then be stored in a database 

31 in the metering mechanism 113. 

32 In block 230, the metering mechanism 1 1 3 encrypts, compresses and packages the 

33 metrics data for transmission to the server side 1 15, and then transmits the data package. 

34 Transmission of the data package may normally be initiated by the metering mechanism 
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1 113, when the metering mechanism 113 is implemented at the client side 110. When 

2 implemented at the server side 115, the metric mechanism 113 may initiate on-demand 

3 transmission of the metrics data. In both embodiments, the transmission may occur at 

4 pre-determined intervals, or when other criteria, such as accumulation of a specified 

5 number of bytes, are satisfied. 

6 In block 235, the validation server 121 at the server side 115 receives the data 

7 package, decompresses and decrypts the data package, stores the decrypted data, and 

8 performs any desired data validation routines, including routines to verify the 

9 configuration of the hardware products 112. In block 237, the validation server 121 

10 determines, based on execution of the validation routines, if the metrics data are valid, 

11 and if the hardware product configuration is unchanged. If both conditions are met, the 

12 operation moves to block 240. Otherwise, the operation 200 moves to block 239, and an 

13 error message is generated. Following block 239, the operation 200 moves to block 270 

14 and ends. 

15 In block 240, the validation server 121 processes the metrics data according to the 

16 pay-per-use pricing plan for the client side 110. In block 245, the processed metrics data 

17 are saved in the usage database 123 . 

1 8 In block 250, after sufficient processed metrics data have been stored in the usage 

19 database 123, the validation server 121 generates a usage report, saves the usage report in 

20 the usage database 123, and provides the usage report to the portal 130 and the billing and 

21 accounting system 140. In block 255, the billing system 141 generates an electronic 

22 invoice, and posts the invoice at the portal 130. In block 260, the portal 130 presents the 

23 invoice to the client side 110. Such presentment may be by way of an e-mail notification, 

24 or by sending the invoice directly to the client side 110. In block 265, the server side 1 1 5 

25 receives payment based on the invoice. Such payment may be by way of electronic funds 

26 transfer, for example. The operation 200 then moves to block 270 and ends. 

27 While the hardware pay-per-use system and corresponding method have been 

28 described in connection with exemplary embodiments, one of ordinary skill in the art will 

29 readily recognize that the concepts discussed herein may be extended to other variations 

30 and embodiments, and that this application would cover those variations. 
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